Every MES rollout eventually hits the same wall. The genealogy report has gaps. The OEE numbers don’t reconcile with what the operators know happened on the line. Someone blames the MES vendor, or the historian, or the integrator. Usually the real problem is upstream of all of them: the PLC and SCADA layer never captured the data the model needed in the first place. Not because anyone was careless, but because nobody wrote down what “the model” actually requires at the attribute level before commissioning started.
That’s what this piece is about. Not batch versus unit genealogy, not UNS design patterns — the more basic question of what ISA-95 assumes exists in your equipment and process data before any of those downstream decisions can even be evaluated fairly.
ISA-95 in one paragraph, for people who skipped it
ISA-95 (formally IEC/ISA-62264) is the standard that defines how enterprise systems (ERP) and control systems (PLC/SCADA/DCS) exchange information about manufacturing operations. Part 1 gives you the equipment hierarchy model and general activity model. Part 2 defines the object models — the actual data structures — for equipment, material, personnel, and process segment information. Part 3 covers detailed activity models for MES functions like scheduling and tracking. Part 4 extends the object models specifically for production scheduling and production performance, which is where genealogy and OEE data actually live.
The standard doesn’t tell you which historian to buy or how to wire a PLC. It tells you what categories of information have to be associated with a production event for that event to be traceable and analyzable later. Genealogy and OEE are both just queries against that information. If the attributes aren’t captured at the point of production, no amount of clever reporting fixes it after the fact.
The equipment hierarchy: not just a tag naming convention
ISA-95 Part 1 defines the equipment hierarchy as Enterprise → Site → Area → Process Cell (or Production Line) → Unit → Equipment Module. This looks like a naming convention, and a lot of shops treat it that way — they’ll structure tag paths like Site.Area.Line.Station and call it done. But the hierarchy is doing real modeling work, not just organizing folders.
Each level in the hierarchy is supposed to carry equipment capability — what that piece of equipment or that work center is actually capable of doing, and under what conditions. That’s an attribute set, not a label: capability type (e.g., “can run product family X”), capacity, and any constraints (max batch size, tooling required, qualified operators). Without capability attributes attached to the hierarchy, MES has no basis for validating that a work order was even executable on the equipment it was routed to — which means OEE availability and performance losses can’t be attributed correctly, because the system doesn’t know what “correct” performance looked like for that specific equipment state.
What this means for your tags
If your PLC exposes a station’s run state and cycle count but nothing that identifies which product/recipe combination the station was configured for at that moment, you have equipment status but not equipment capability. That’s the first audit point: for every asset in your hierarchy, can you answer “what was this equipment configured and qualified to produce, at the timestamp of this event”? If the answer lives only in an operator’s head or a paper traveler, it’s not genealogy-ready.
The material model: lot ID is necessary, not sufficient
Part 2’s material model defines material class, material definition, material lot, and material sublot, along with properties that travel with each. Most plants get the headline right — they assign lot numbers to incoming material and to output. Where it breaks down is in the properties and the sublot relationships.
Genealogy requires knowing not just that Lot 4471 went into the process, but the quantity consumed, the material sublot if the lot was split or partially consumed, and the property values that were relevant to that specific consumption event (a moisture reading, a viscosity check, a certificate of analysis reference). A lot ID field on a PLC recipe tag without a linked consumption quantity and timestamp gives you “this lot was used somewhere in this order” — not “this lot, in this quantity, at this process segment, produced this specific output sublot.” That distinction is the entire difference between usable genealogy and a compliance liability during a recall.
The process segment: where OEE actually gets its teeth
This is the part most tag structures skip entirely. ISA-95 Part 4’s process segment model defines a segment as a logical grouping of activity within a process — a defined piece of work with its own required resources (equipment, material, personnel) and, critically, its own segment response: the actual recorded outcome of that segment, including actual duration, actual resource consumption, and actual output, measured against what was planned.
OEE depends entirely on segment response data existing and being complete. Availability loss is the gap between planned and actual segment duration. Performance loss is the gap between the segment’s rated capability (from the equipment model above) and its actual throughput. Quality loss is the gap between segment output and good output. If your SCADA layer captures start/stop timestamps but never captures planned duration or rated capability against a segment ID, you can compute a cycle time — but you can’t compute a defensible OEE number, because there’s nothing to compare the actual against.
The personnel model: usually the most incomplete
Part 2 also defines personnel class, qualification, and person — meant to answer “was the person operating this segment qualified to do so.” In practice, most plants log operator ID as a badge scan for time and attendance, disconnected from the segment or lot record. For genealogy purposes this matters more than people expect, particularly in regulated industries: a deviation investigation often needs to know not just which equipment and lot were involved, but which qualified operator executed which segment. If operator ID isn’t a field on the same event record as the lot consumption and segment response, you have three disconnected logs instead of one traceable record.
A single work order, walked through the model
Take one work order for a batch of a coated tablet, moving through blending, coating, and packaging.
At the equipment level, the blender tag structure needs: equipment ID, current capability configuration (blend recipe class it’s set up for), and status. At the material level, each raw material lot consumed into that blend needs: lot ID, sublot if split, quantity consumed, and the specific property values checked at intake. At the process segment level, the blending segment needs: segment ID, planned duration and rated throughput pulled from the equipment’s capability record, actual start/stop timestamps, actual quantity processed, and quality result. At the personnel level: operator ID tied to that specific segment execution, not just a shift log.
Do that at every segment — blending, coating, packaging — and the output lot of tablets carries a complete chain: which equipment, which material lots and quantities, which segment performance against plan, which personnel. That chain is genealogy. The segment response records, aggregated, are OEE. Skip any one attribute at any one segment and you get a report with a hole in it that nobody notices until an audit or a customer complaint forces someone to go looking.
The audit you can run this week
Pick one work order that ran recently. For each equipment, material, segment, and personnel touchpoint it passed through, ask: is capability captured, not just status? Is quantity and sublot captured, not just lot ID? Is planned-versus-actual captured at the segment level, not just timestamps? Is the qualified operator tied to the specific segment, not just a shift record? Wherever the answer is no, that’s not a reporting gap you’ll fix in the MES configuration screen. It’s a tag structure and data capture gap, and it has to be fixed at the PLC/SCADA layer before any genealogy or OEE strategy built on top of it will hold up.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
